Skip to main content
Expert Talk
Amakomaya — Aamako Maya Apps Pvt. Ltd.

Enterprise Architecture

Enterprise architecture is the part of the work that happens before anyone chooses software. In health it is usually skipped, which is why so many ministries own several systems that each hold part of a patient's record and none that holds the patient.

The value is not the diagrams. It is being able to answer, for any proposed system: which capability does this provide, who is accountable for it, and what happens to the three systems that already claim to provide it?

Business architecture​

What the health system is accountable for, expressed without reference to software.

Artefacts worth producing:

  • Stakeholder map — clients, providers, facility managers, district and provincial authorities, ministry programmes, insurers, donors, regulators. Each has different data needs and different authority.
  • Service catalogue — the health services actually delivered: antenatal care, immunisation, TB treatment, outpatient consultation, referral, procurement.
  • Outcome measures — what would have to change for the investment to have been worth it. If nobody can name these, no architecture will fix the problem.

The test: a business architecture is real when a programme manager recognises their work in it without translation.

Capability architecture​

A capability is something the system must be able to do, stated so that it stays true regardless of which product provides it. "Uniquely identify a client across facilities" is a capability. "Deploy OpenCR" is not.

A workable capability model for a national health system:

Client-facing                Provider-facing              System management
─────────────                ───────────────              ─────────────────
Client identification        Clinical documentation       Facility management
Client communication         Decision support             Health workforce mgmt
Appointment / recall         Order and result mgmt        Supply chain mgmt
Consent management           Referral and transfer        Financing and claims
Personal health record       Prescribing and dispensing   Performance monitoring

Data services
─────────────
Data collection · Data exchange · Terminology · Reporting and dashboards
Data storage and aggregation · Surveillance and alerting

This mirrors the structure of the WHO Classification of Digital Health Interventions, which is worth adopting directly rather than inventing a local taxonomy — it makes your capability model comparable with everyone else's.

Use it for portfolio analysis. Plot existing systems against capabilities:

CapabilitySystem A (EMR)System B (HMIS)System C (CHW app)Gap?
Client identificationLocal IDs onlyNoneLocal IDs onlyYes — no shared identity
Clinical documentationYesNoPartialOverlap
Aggregate reportingExportYesExportDuplication

Two things fall out of this table immediately: the capabilities nobody provides (build or buy) and the capabilities three systems each provide badly (consolidate). Most national digital health strategies would be better documents if they contained this table.

Process architecture​

How the work flows, in the order it actually happens, including the paper steps.

Model processes in BPMN where the model will be reused — WHO Digital Adaptation Kits use BPMN precisely so that a workflow can be handed to implementers unambiguously. For internal understanding, a swimlane sketch is often enough.

What to capture per process:

  1. Actors and where they are — including whether they have connectivity
  2. Trigger — what starts it
  3. Decision points — and the rule behind each one
  4. Data created or needed — at each step
  5. Handoffs — where the process crosses an organisational boundary, because that is where information is lost
  6. Exceptions — the referral that fails, the client who does not return

Point 5 is the one that matters architecturally. Every organisational handoff is an integration requirement. Counting handoffs in the priority workflows is a fast way to size an exchange programme.

Information architecture​

Agreeing what the words mean, before any system stores them.

The questions that cause the most damage when left unanswered:

  • Who is a "patient"? One person, one record — across facilities, over a lifetime, including newborns without an identifier yet.
  • What is an "encounter"? A visit? A contact with one provider? A day? Aggregate indicators built on inconsistent encounter definitions are not comparable between districts.
  • What is a "facility"? A building, a licence, a reporting unit, or a service delivery point? These differ, and each system usually picks a different one.
  • What is an "episode of care"? A pregnancy, a TB treatment course, a chronic condition — the unit that makes longitudinal care legible.
  • Which identifier is authoritative? And what happens when it is absent, wrong, or shared by two people?

These answers become the registries and the terminology. They are the most expensive decisions to reverse in the whole architecture, and they are usually made by accident, by whichever system was procured first.

Application and technology architecture​

Once the layers above are settled, these become tractable:

  • Application architecture — which system provides which capability, what it owns as master data, and what it consumes. The rule worth enforcing: one system is the source of truth for each data domain; the rest hold copies and know they are copies.
  • Technology architecture — hosting, networks, runtime, and the operational capacity to run them. See infrastructure.

Governance architecture​

Architecture decays without a body that maintains it. Minimally:

  • An architecture review board with authority over procurement — an architecture that cannot block a purchase is advisory only
  • A standards register — which versions of which standards are current
  • A decision log — ADRs
  • A change process — how a new system joins the ecosystem, and what it must prove first

See governance.

A minimum viable enterprise architecture​

For a team that cannot resource full EA, five artefacts carry most of the value:

  1. Capability model, mapped to existing systems (the gap/overlap table above)
  2. Three to five priority workflows, with handoffs marked
  3. Information model for patient, encounter, facility, provider
  4. Standards register
  5. Decision log

That is a week or two of work and it changes what gets procured.

References​

Last updated on